The present disclosure relates generally to information handling systems (IHS), and more particularly to a modular advanced configuration and power interface (ACPI) source language (ASL) for an IHS.
As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option is an information handling system (IHS). An IHS generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes. Because technology and information handling needs and requirements may vary between different applications, IHSs may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in IHSs allow for IHSs to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, IHSs may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
IHS design is moving from basic input/output (BIOS) architecture to extensible firmware interface (EFI) architecture which is modular in nature. The EFI is generally known as a specification/system that defines a software interface between an operating system and platform firmware. A form of EFI is also known as unified EFI (UEFI). BIOS modules/drivers generally interact with other drivers in terms of protocol & event. Drivers register for a specific event and other drivers broadcast the event that causes those pending event methods to be invoked. An event is generally known by those having skill in the art as an action in an IHS that may be initiated by the user, a device (e.g., a timer, a keyboard, and a variety of other devices) or by the operating system. In event driven programming, the flow of the program is generally determined by the events, such as user actions or messages from other programs.
A problem arises with this architecture for advanced configuration and power interface (ACPI) components. ACPI components commonly use ACPI source language (ASL). However, ASL traditionally does not support such a modular concept. The BIOS ACPI components are generally written in a very primitive ASL language that does not follow advanced programming methods, such as callbacks, methods registration and indirect method invocation. Thus, the ASL language poses many challenges to BIOS programmers. For example, one ACPI method may need to call other ACPI methods by the same name. ASL does not have a concept of broadcasting an event to other ASL method. Currently the ASL event method explicitly calls out each of the interested methods that need to act on such event. It is very difficult to integrate ASL modules from various product vendors because one module needs to know the scope, names and parameter of the other dependent modules. This causes a challenge for BIOS writers to isolate the ASL modules as each ASL module directly calls out functions in other ASL component. Also when writing an ASL code that interacts with various platform behavior, chipset, feature etc. the code becomes very convoluted and the code developer adds a build time conditional statement (for example. #if< >/#else statement) in the files so that ASL code behavior can change based on platform, feature, chipset and etc.
When writing ASL code there is a need to build the modular concept (similar to UEFI) so that each ASL module can be separately written without the knowledge of other modules and so each module can interact with other modules via an event mechanism.
Accordingly, it would be desirable to provide an improved modular ASL absent the disadvantages discussed above.